The 640 MEG Shareware Studio 2/The 640 Meg Shareware Studio CD-ROM Volume II (Data Express)(1993).ISO/mail/xr499new.zip/NEWIN499.DOC

Text File | 1991-12-12 | 61KB | 1,018 lines

Changes from XRS v 4.50 -=> v 4.99 wide beta (prerelease of XRS 5.0):

0) Version 4.99 is compiled with Borland C++ 3.0 - full speed optimization
 turned on.  The executables are slightly fatter but noticably quicker!
 Unfortunately there is also a bug in the "exec..()" routines used when you
 tell XRS to "Restart?" itself, and this currently doesn't work - I have
 reported the problem to Borland and they are "hard at work" on it, so they
 say... (for three weeks, now)  This compiler "inlines" several intrinsic
 functions for even better response in most areas!  20-30% on some machines!

1) Even better video response (less delays) under DesqView!

2) Snow fixed one more time.  Should eliminate all snow on CGA monitors!

3) XRS supports *any* screen geometry a minimum of 80 lines by 25 rows,
 including 90, 100, 128, 132 width sizes - up to 160 width!  It has been
 tested at both 100x75 lines and 132x45 lines with no problems.  If any
 program you use externally in the shell (<F10> or <Shift_F10>) alters the
 video geometry, XRS will automatically restore it when you return by
 'exit'ing back into XRS.  Remember - if you use a soft font, you must
 put "Soft Font" into CONFIG.XRS, if it is a hardware-created font - not!
 (use the "MODE x" parameter in CONFIG.XRS instead - it *does* understand
 non-standard modes!)  Most things take into account the larger width of
 the screen, but display output still "wraps" at column 79 on the display
 side (since creating quotes longer than that will surely cause problems!).
 If you "SET XRS=X" before you start the program, any MODE statement will
 not take affect.  If the screen geometry is not 25 x 80, it is displayed
 next to the video monitor type in the <F2> hot-keyed status window.  In
 adding > 80 column support to XRS, it became painfully apparent how few
 programs support this, and even more so how few do it well.  You're mostly
 on-your-own here, but I swear - "it works here" - even 100 column by 75
 line mode under OS/2!  Note that if XRS detects that it is already in the
 "MODE xx" you specify, it does not adjust the screen, also any extended
 mode parameter (i.e. "MODE 43 100 5" to set extended video attributes)
 will override normal functions and always use that specific mode.  The
 extended mode parameters specify values to load into _AL and/or _AH to
 set board such as the Headlands/Video7 "VRAM" and "1024i".

4) All the old CXL code was replaced with equivalent TCXL code - should
 make the overall size smaller, since a few were duplicates being used
 from both libraries that performed identical functions.

5) More detailed information on what type of monitor you have is displayed
 (i.e. "MCGAMono", "Herc+", "InColor", "SVGA", etc).

6) Added ability to change to force 8x8 character mode (via new CONFIG.XRS
 parameter "8x8").  This could potentially force your video monitor into a
 higher lines-per-screen mode than normally accessable when used with a
 forced "MODE x" parameter that sets up a non-standard video geometry (my
 Orchid ProDesigner/II VGA Sierra HiColor can be pushed to a 75 line x 100
 width mode, for example - "PSMODE 2A" plus 8x8)  If this is in your config
 file, XRS will always force the mode before it starts the C_Worthy system,
 so all screen dimensions will be correct.  It does so by loading the _BL
 register with 0 and the _AX register with 1112 and generating interrupt
 0x10, which should work in all cases.   If this method does not work on
 your system, please send me screen-dumps!  (hit the <CTRL_F10> hot-key to
 dump to $XRS$PRT.SCR, which is now correctly formatted for non-80 width
 screen-dumps.  The '8x8' parameter overrides "Soft Font" parameter.  Note
 that XRS no longer auto-adjusts the screen-size at run-time ever (but if
 you use this parameter, you can have 43- (EGA) or 50-line (VGA) modes).
 Basically, the "SET XRS=" parameter is obsolete, unless it is set to
 "DDOS" to avoid video bleeding through to another screen.

7) When you use <TAB> to export a message you wrote (from the "Create/Edit
 /Delete" sub-menu) the extra line exported when you end a message with a
 <CR> is no longer printed.  (I added this bug to 4.52 "fixing" the missing
 line when you *didn't* have <CR> on the last line!)

8) XRS has always defaults to "Crash" netmail (if you have a choice) for
 mail inside your own zone, and "not Crash" for mail destined to another
 zone.  If you want XRS to always default to "not Crash" all the time, use
 "Don't Crash" in your CONFIG.XRS file.

9) "SafeMode" in your CONFIG.XRS file will save your progress automatically
 every 10 messages you read, in case you are in a house prone to lightning
 or power failure (or short fuses).  You can optionally append an exact
 number of message to skip between updates (to optimize for your machine)
 by appending a number from 1 to 20 - if you try to set it higher than 20,
 it will be reset to 20.  (The default if you don't specify this is every
 10 messages.)  XRS displays a message to let you know that it is doing the
 automatic safe mode update whenever it saves your progress.  Setting it to
 "SafeMode 1" will slow you down a little, but guarantees you'll never lose
 your place in a mailbag (because the file is updated with every message)!
 Also, XRS saves the mail progress if you hit <F10> or <Shift_F10> for a DOS
 shell or command (and does so before prompting you for a DOS command).

10) You can force XRS to prompt you for the area to place each message each
 time (instead of defaulting to placing it in the current area) by using
 "Area Prompt" in CONFIG.XRS - this just pops up the message area with the
 current area highlighted and lets you pick the area.  Also, a new item on
 the <F4> hot-keyed configuration menu "Change Area" On/Off allows you to
 turn this on and off so it only prompts you for an area change if you are
 going to change the area instead of every time, plus it also cycles through
 the options for prompting "To Name" as well.  You can turn either or both
 on at one time, or turn them both off.  (You cannot change this parameter
 when you are in the editor or about to quote/reply to a message or create a
 new message - until you get out of "new message" mode.)

11) XRS word-wraps output to any TTY device (i.e. LPTx: or CON:) the same
 width is would on-screen (79 characters, or one less than your screen
 width if you are writing to CON: - if you write to LPT1:, it is always
 'fixed' word-wrapped at column 79), and if you have "Form Feed" in your
 CONFIG.XRS file, it no longer prints the "=-=-=-=" bar at the bottom if
 the output device is LPT1:.  This should provide perfectly formatted
 messages when exported to LPT1: or PRN:, including Form Feed will kick
 out a page as well!  XRS uses the "isatty()" function to determine if it
 is writing to a TTY type output device, and acts accordingly - if not,
 then a standard file formatted as before (without word-wrap) is written.
 You can adjust the "Printwidth xxx" in CONFIG.XRS (to anything between 40
 and 160 - default is 80 columns) if your printer is not an 80-column one.

12) Fixed repacking of QWK format mailbags with fewer than eight character
 BBS_ID mailbag names.

13) Fixed problem(s) with swapping out during DOS Shell under OS/2 and
 eliminated the problem clearing the screen under OS/2 as well.  Under
 OS/2 you should have the C:\OS2\ANSI.SYS driver or an equivalent loaded,
 just as you should have the ANSI driver loaded on any other platform.
 If you are in Desqview, you need to load "DVANSI".

15) XRS should correctly identify and display the 386^Max memory manager
 presense and internal version number on the <F2> display.  This version has
 been thoroughly tested with both 386-to-the-Max 6.00 and v 6.02 of QEMM386.

16) Macros which start out > 80 characters are now supported (up to 128)
 and macro substitution can allow up to 160 characters total.  Macros will
 automatically word-wrap if they go over one line.  See below (#??) for
 more about "substitution" meta-characters.

17) The DPMI and VCPI subversion number is correctly displayed (in decimal
 instead of hex) in the <F2> status window.

18) With RTLink+ 5.0 used for linking, the distinction between overlayed and
 non-OVL versions is obsolete.  Since you can control how much of each type of
 memory - low "640K" RAM, "Expanded" and "Extended" (XMS) is used to cache the
 program.  Normally the program runs in cached LIM or XMS mode, allocating
 128K of LIM/EMS 3.2 (or later) memory or 128K of XMS extended memory if there
 is no expanded memory.  If you have neither and do not want the program to
 execute slower with non-cached run-time linking, use the new "LOW_RAM.BAT"
 file to set several "SET RTOVxxxx=yyy" environment variables, and then the
 program will run at full-speed in "Low (640K) RAM" instead.  It will perform
 exactly like previous non-overlayed versions.  There are only two versions
 of the executable - the 'generic' "RESP_OVL.EXE" that requires "RESP_OVL.DLL"
 and the "'286" (runs on NEC V20/V30, too) version "RESP_RTL.EXE" requiring
 "RESP_RTL.DLL".  See the file "REQUIRED.RAM" for precise details on both the
 amount of memory required and the variety of options for fine-tuning memory
 and memory type usage.  Using the various setable run-time allocations, you
 can force the same XRS program to run in either overlayed mode in cached or
 non-cached modes, or in overlayed mode.  "RESPONSE.BAT" and "RESP_286.BAT"
 files are provided to allow those used to using those versions easy access to
 the exact same functionality without having to remember to use new commands.
 Note that if you already have batch files which call "RESPONSE X" or
 "RESP_286 X" (for example), you must replace the command with a "CALL
 RESPONSE X" - since RESPONSE is a batch file now. (but RESP_OVL.EXE and
 RESP_RTL.EXE are still programs)  This also greatly simplifies (and shrinks
 size-wise) each distribution!  The entire v 4.99 BBS-downloadable release is
 only 60% the size of the 4.51 version...

19) The "Subject" field it 'trimmed' (of extra spaces at the end) before
 substitution in macros or message quote headers.

20) When a user tries to enter a message into an area that requires an
 alias and either doesn't have one, or hasn't activated alias support on
 the BBS side, he is given an error message and cannot enter a message.
 Also, when he pops up a list of areas to write a new message, if he does
 not have an alias or hasn't turned on alias support, "Alias Required"
 areas are not in the list.  This is also true during message read - if he
 is in an alias required area, and has no alias or did not turn on alias
 support, he cannot <Q>uote or <R>eply.

21) "No Bell" (via any command-line parameter) should be more global.

22) You can no longer accidentally end up in the "Inbound" subdirectory
 if you shell out when XRS is looking for inbound mailbags.

32) A new "XRS-Sort.Exe" preprocess module is included (version 1.0) that
 sorts up to 7500 message mailbags.  (XRSORT10.ZIP)  This is a maximum,
 and the upper limit will vary with the amount of free memory and whether
 or not you have "Swap" enabled.  If you cannot sort a mailbag inside XRS
 you may want to exit and try running XRS-Sort from the command-line since
 more memory would be free that way.

33) When you hit <F1> twice, it has descriptions for keys F2, F4, F6, F8,
 & F10 which were lost in the code - also added CTRL_F10 (Screen Dump).

34) Ralf Brown's "SpawnO()" routines are used for both swap-to-DOS and
 swapping out XRS when calling external programs if "SWAP" is enabled.
 This routine leaves only a 240 to 320 byte stub in memory, and swaps to
 XMS first, EMS second, raw extended (interrupt 15) if you don't run under
 a multitasker (like Desqview) and finally to disk.  If you have XMS or EMS
 memory, it is shown along with detailed description of where you currently
 can swap out XRS (in the <F2> hot-key status window).

35) XRS doesn't disable EMS memory handling for OS/2 version 2.0 betas.
 If you don't provide any virtual EMS memory to your DOS machines, you
 should put "NO EMS" into your CONFIG.XRS file if you run OS/2 2.0!

36) The command interpreter is no longer invoked twice for non-swapped
 DOS command (via the <SHIFT_F10> hot-key).

37) The "Edit Info" does not bleed over the help screens.

38) The garbage on the command-line when using a "Bundler" parameter is
 removed (and therefore alternative packers should work again).

39) The cursor is no longer 'invisible' during DOS shell until the screen
 is cleared or scrolled, or backspaced over.

40) If you hit <ESCape> while the "DOS Command" prompt is on-screen, you
 do not exit to a DOS shell - you return to where you were in the program.
 You can use this to "cheat" and save your progress if you do not normally
 use "SafeMode" because it saves your progress *before* prompting you...

41) XRS no longer deletes all "??.MSG" messages using a single FCB kill
 call (it uses "system("DEL ??.MSG");" instead.  (4DOS no longer objects)

42) Subject ("%s") in echomail headers is from current message (not prior).

43) The bug that caused messages to "fly by" without you seeing them if you
 used <F7> during <J>ump to mark them all unread, and then replied to one
 is fixed.

44) If you have no EMS memory at startup and don't use "No EMS" in your
 CONFIG.XRS file, wierd things don't happen sometimes - especially when
 using the command-line parameter to make XRS be quiet.

45) Worked around a bug that caused the <F6> "Summary/Index" display to go
 blank if the first key you hit was "Down" or "PageDown".

46) "xx% of your message is quotes!" message is in your native language.

47) XRS has an internal "HeapCheck" and "HeapWalk" facility, which is
 "hidden" on <F2> after the normal <F2> status display is on-screen.  It
 will either display "Heap Corrupted" (in which case something has really
 messed up!) or it will walk the heap, listing size, location and status
 for each item and finally grand totals for allocation and number of items.

48) If you don't have a "CONFIG.XRS" file at all (how could you at this
 point?) then truly wierd things don't happen with the video, etc.







Changes from XRS beta v 4.51 -=> v 4.52 wide beta (Released 7-Nov-91):


1) Updated to TCXL 5.52.05 - should fix CGA "Snow" (again).

2) Fixed three separate bugs in the TCXL 5.52.05 "UMB" memory support code.

3) Fixed a bug in the HeapXpander startup code that would allow it to copy
 from a NULL pointer if the "HX" string was not set in the environment.
 (I sure am getting tired of fixing other people's code! <grin>...)

4) As part of better supporting DOS 5.00, QEMM 6.00 and HiMem.Sys 3.0 (XMS)
 programs I now detect and use all UMB (Upper Memory Block) areas created by
 QEMM or HiMem.  The new QEMM 6.0 Stealth technology can typically leave up
 to 210K free available UMBs, and I suppose the new QRAM will do the same for
 80286 machines.  Saving of screens is always done in UMBs if possible, since
 they are easily allocable in 16-byte chunks.  (A typical 80x25 screen takes
 4000 bytes to store - I have successfully run XRS in up to 80x75 line mode,
 which would take 12000 bytes to save!  This saves a considerable amount of
 low memory when you are several layers deep in the program!)  Editor, backup
 buffers and related file import buffers and the 8K file buffer (or whatever
 size you set with "Buffer") for BATxMAIL.XRS are also allocated from the UMBs
 if possible also and released when no longer needed.  If you have a large
 enough UMB block free, this will decrease the amount of "Low" (640K) RAM you
 need by the size of the buffer - default is 10K but you can change it with a
 CONFIG.XRS "EditBuffer xxxx" parameter.  "ShowSummary" (on the <F6> hot-key)
 is allocated in a UMB if possible.  The big advantage to allocating things in
 UMBs is that they are directly addressable by all DOS commands just as if
 they were in the lower 640K and other than freeing them, you treat them
 exactly as if they were there (and accesses are at the same speed as "Low"
 RAM).  "All of the above" can save you a minimum of 20K "Low" memory, and up
 to a potential of 150K or more if you set the buffer size high (and you have
 the needed UMBs).  Note that this also reduces the amount of memory you have
 to swap out if you enable "Swap", since data in UMBs do not need to be saved
 and restored, which makes swapping out slightly faster.  Buffers for any
 imported files are always allocated in low memory.  Since these buffers are
 infrequently used and very quickly disposed, allocating them from UMBs and
 immediately releasing them is slower than normal RAM.  You can totally
 disable all UMB support by putting "No UMB" in your CONFIG.XRS file.  I
 don't know of any reason or problem with any use of Upper Memory Blocks why
 you would ever want to disable this, but just in case you do...  Not all
 UMB-providers are created equal, and in some cases I've found (especially
 with 386SX machines) they just don't work as they should.  I have found that
 both my 386/33 machines run just fine using the normal UMB stashing of the
 file and editor buffers, video screen saves, etc but my 386sx20 gets stupid
 at the same spot - using the same (QEMM 6.02) memory manager (oh, well - I
 probably just don't have it set up right!)...  An Upper Memory Block once
 allocated should be just like any other block of memory to any DOS function
 (interrupt) call - it is just a pointer to an area of memory that normally
 didn't have RAM there under earlier versions of DOS and QEMM/etc.  However,
 I have found that copying directly from one UMB block to another on 386sx
 machines usually hangs (and therefore I don't do that.  Since the UMB
 functions provided for UMB management involve a sum-total of two calls, one
 to claim or allocate the memory and one to release it, I can only assume
 that this is yet another case of "I'm ready but you're not"...

6) Added CONFIG.XRS option "Form Feed" which causes "eXport" messages to have
 a Form Feed added to the end of them if they are exported to a printer
 device (i.e. PRN: or LPT1:, etc).

7) Fixed "BufferWarn" line counter to distinguish between hard returns and
 soft returns (word-wrap) to accurately tally number of characters that will
 be written - which is not exactly the same as the count in the edit buffer.

8) Fixed the way the final "ExitProc()" called when you leave the program
 cleans up the old portal, and returns to the "Main" portal.

9) Moved things around in the overlay structure, further reducing minimum
 memory "footprint".  There are now six overlays totalling 128K, and the
 memory requirements for the overlayed versions are no more than any previous
 4.xx release, still!  They are also more 'balanced' in size than before.

10) I look for "4D?PACK.XRS" instead of 4D_PACK.XRS so I can change it to
 "4D-PACK.XRS" instead.  (The underscore hoses Paul Martin's CP/M XRS clone.)

11) The display of the address and "True 4D" or "Pointnet xxx" is fixed in the
 internal "XRS_Pack()" FTS-0001 packer.

12) The 4D capability word and complement (validation) bytes are set in the
 packet headers if 4D is enabled.  Apparently, some of the newer programs use
 it as a "key" even though it is only a proposal and not an accepted standard.

13) The "$XRS$PRT.SCR" file header shows "NoneOpen" instead of screwing up if
 you hit <CTRL_F10> before you open a mailbag or get past the selection point.

14) When you pack outbound mail, the rodent no longer dies if it was on.

15) When you drop to DOS with <F10> or <Shift_F10> and/or use a program that
 turns the mouse on and back off, the rodent is resucitated upon return.

16) Instead of 'segregating' mailbag compression types, XRS displays available
 mailbags of all flavors (including *.QW?) at one time.  Even if a mailbag is
 named incorrectly for its compression type, XRS will detect the flavor and
 use the proper extraction program.

17) If the "Alias Allowed" bit is set in ACCESSx.XRS for an area, XRS prompts
 you with "Use Your Alias Name?".  If you say "Yes" (the default), then your
 alias will be used instead of your real name, if you say "No", then your real
 name is used.  Note that aliases are only fully supported if the BBS is using
 the most recent XRSDoor 2.04 (or later) mailbagger *AND* you set the "Option
 Toggle" indicating you are using XRS 4.52 or later!  If your alias is the
 same as your "real" name in the file, alias support is disabled.  Note that
 XRS "remembers" whether the alias flag is set when you alter the header using
 <F3> in the "Create/Edit/Delete Messages" list as well as the private status.
 The list now has "?" in front of the "To Name" field if you used your alias.
 You must enable alias support on the BBS by setting the '<O>ption Toggle' in
 the configuration section labeled "Using XRS 4.52 or later?" *ON*.  NOTE:
 previous versions of XRS choke on the user file if alias support is enabled!

18) New "CONFIG.XRS" parameter "Force Alias" will skip the "Use Your Alias?"
 prompt for areas where aliases are optional and always use your alias.

19) To allow for the alias to be stored in RESPONSE.XRS (the outbound message
 headers file), the message number (which used to be an integer) is now a BYTE
 field, followed by another BYTE field which is the alias flag.  If the alias
 byte is on (i.e. non-zero), then the alias should be used, if it is zero then
 the real name should be used.  (this information is really only important to
 XRS add-on authors...)

21) New CONFIG.XRS parameter "Attribution xxx" allows a custom "In a message"
 quote header string to be built (possibly in your native language) and can
 have 'substitution' strings in them.  For now, these are limited to: "%f"
 for the 'From Name' of the message you are quoting, "%t" for the 'To Name'
 of the quoted message, "%d" for the date/time it was sent, "%s" for subject,
 "%a" for the area, "%u" for you (your name or alias if using the alias, "%1"
 for the first name of the person you are quoting and "%n" for 'now' - the
 current date and time.  'xxx' may not exceed 80 characters, and the expanded
 header may not exceed a total of 159 characters or it will be truncated.
 Underscores are removed (turned into spaces), and pipe symbols ('|') are
 translated to <CR> (new line) characters.  (in other words,
    "Attribution In a message to %t <%d> %f wrote:||"
 is the English version of the "standard" quote header and need not be
 specified.)  Note that only the English "In a message"... is recognized by
 the special routine that colors those lines differently.  Putting a different
 "Attribution" in the CONFIG.XRS file does *not* automatically enable quote
 headers - you still need to put "Quote Headers" in if that is what you want
 by default (though you can turn it off from the <F4> window).

22) The corresponding quote header for netmail "In a Matrix message of <%d>
 you wrote:||" can also be changed with "NetmailHeader xxx" in the CONFIG.XRS
 parameter file - the same substitutions and limitations listed above apply.

23) The problem which cause "double vision" on the mouse cursor is fixed.

24) To allow the internal editor buffer size to be dynamically allocated to a
 minimum of the default edit buffer size and a larger number (to allow you to
 quote larger messages, chopping out irrelevant portions) - set new parameter
 "DynamicBuffer xxxxx" in CONFIG.XRS which allow the buffer to float between
 twice the editor default (10K unless you adjust it) and this number (which
 must be higher, or it is ignored).  Maximum is 65500 bytes.  Setting this to
 a value higher than 12,000 may earn you a warning message from "GMD" (the
 "Grunged Mail Detector") running on the Fidonet backbone.  XRS reserves 10%
 'cushion' for expansion during "Edit File", so the largest file you can edit
 is around 59000 bytes, although you can import text into a file and get as
 much as around 65000 characters total (the buffer size is reduced by the
 number of soft carriage returns or word-wraps in the buffer when it is
 written).  Note that you *can* adjust this "down" to 10K, in which case no
 dynamic buffering will be done (and you will need less memory to edit files,
 but you won't be able to quote larger messages), but the default is 2 times
 the buffersize, or 20K.  This should be sufficient to edit (and quote) any
 messages transported on FidoNet (or QWK-based systems).  It is unlikely that
 you will ever need to adjust this parameter, if you do - your should set it
 to the actual value you want to use as the maximum (not half that amount).
 XRS will automatically "slide" between the editor buffer default size and
 about 10% larger than the message being quoted, but never exceeding this
 value - if the message to be quoted exceeds this value plus a 10% 'cushion',
 it will not be quotable.  Also - you can never import a file larger than the
 "Editbuffer" size, but you can insert a file into a new message up to
 "Dynamicsize" less 10%.  I also found the coding error which allowed old
 versions of XRS to miscalculate the required quote buffer size and overrun
 it writing over other things (data & code?) causing the old lockups and
 "AlignChangeList" error.

25) The internal editor buffer "rewrap" routine after a macro or file import
 (using the <ALT_F4> hot-key) is fixed.  I changed the way the macros and
 <ALT_F4> import file function work again.  This time it works by freeing the
 "editPasteBuffer" (is not NULL) and then inserts either the macro or the
 imported file into it, and forces EditText() to insert it from the buffer.
 This means the macro or file is still in the paste buffer until you cut
 something out again (in other words if you hit <INSERT> (or <F9> depending
 upon whether or not you reversed the two keys) it will be inserted again -
 until you delete a block.

26) The eight macros (stored on the <CTRL_F1> up to <CTRL_F8> hotkeys) can
 have 'substitution' strings in them.  The substitutions are the same as are
 available for the "Attribution" and "NetHeader" above.  Macro key definitions
 no longer require underscores to replace spaces (i.e. "Macro Mean ol' Mike").
 Macro keys are now a maximum of 128 bytes each (instead of the previous 80).

27) XRS is OS/2 aware, and displays the proper version number, etc.  It also
 automatically disables *all* attempts to detect or use LIM/EMS memory.  XRS
 adds "OS/2" to the tear line when it is being run under OS/2 - this support
 will be expanded in the near future to run as a true OS/2 VIO application.

28) "PushQuote()" (the routine which pushes another quote lead-in matching
 the one on the current line) is no longer stumped if you are on the last
 character of a line (which means you are 'sitting' on a soft-CR word-wrap).

29) Some extraneous code which was included for using DOS prior to version 3
 was removed (XRS requires DOS 3.0 or later).

30) The typecast for "strerrmesg()" was corrected in two places.  This could
 have caused some 'unusual' error message or potential lockups if certain
 files were not found or not able to be opened.

31) If the machine you are using returns an 'odd' value for the machine type
 (every machine to date that does has been a 80286), the value "286?" is no
 longer followed by random garbage.

32) Using the <ALT_F7> color palette adjustment routines with overlayed
 versions is no longer fatal (caused lockups after wierd error messages).

33) In tracking down a bug in the <ALT_F7> "Color Palette Adjustment" for
 overlayed versions, I found several functions were prototyped incorrectly
 and this could have also added to the problems.  Both bugs fixed...  This
 also is likely the culprit for a previously reported bug I never could
 track down in non-286 versions being unable to properly save XRSCOLOR.BIN
 updates (which should work exactly the same as 286 versions now).

34) Chief bug hunter Daan van Rooijen noticed that the new XRS!CORE file
 had one very minor inconsistency with prior versions - the "Confirm()"
 procedure routine (hot-keyed 'Yes'/'No' prompts) would not cycle thru the
 top any more.  It works as it used to, now.

35) Much more of the code is compiled with the "-1" ('286) code switch
 resulting in both faster execution for the 286 version and tighter code
 size (and *.EXE & *.DLL files) than the non-286 'generic' version.

36) This isn't really a bug per se, but mostly a clarification of something.
 Several people reported the editor was 'sluggish' with the new "Line x of y
 Column z" and " xxxx free " displayed continuously being updated.  If this
 is true, you should increase your "TimeAdjust xx" above the default to give
 smoother performance.  The default is 8 cycles between updates or 16 cycles
 for the overlayed versions.  Increasing this makes XRS do nothing more times
 before making any screen updates between refreshes, therefore if you are
 constantly moving the cursor, processing keystrokes takes higher priority
 over maintaining the editor status information on the screen.  Setting it
 to 8 with overlayed versions (this is actually *increading* the frequency!)
 gives satisfactory performance on my 386/33.  Making it larger (i.e. 20+)
 should give a less 'mushy' cursor, while potentially letting the onscreen
 editor status information and clock update take less priority.  Depending
 upon the speed of your processor and screen updates, you may need to
 increase this even more.  "Timeadjust" can be set anywhere in the range of 1
 up to 50 cycles delayed between updates.  See below for a new "SlowEdit x"
 parameter which provides an alternate method of "taming" the editor info.

37) The filename for the Dynamically Linked portion required for all versions
 of XRS is now "XRSCORE.DLL".  Lots of code was moved from the root segment
 into the DLL as well.  All *.EXE files are smaller, DLL is slightly larger.

38) XRS allows a "Preprocessor" to manipulate a mailbag immediately after it
 is opened (only new mailbags or if you have "Force New" in CONFIG.XRS).  To
 activate a preprocessor, use "PreProcess xxx" where 'xxx' is a filename to
 execute before loading the summary and index into memory.  This allows you
 to hook a program to sort a mailbag by subject, for example.  'xxx' *must*
 be in the current directory or findable on your PATH and may NOT include a
 complete pathname!

39) "XRS-Sort.Exe" is provided to sort an open mailbag's MAILxIDX.XRS and
 SUMMARYx.XRS files by date within subject within group (AREA:).  Specifying
 "Preprocess XRS-Sort.Exe" will cause XRS to call "XRS-Sort.Exe" immediately
 after opening each new mailbag, or always if you have "Force New" turned on.
 This early version of XRS-Sort can only handle up to 900 messages, since it
 requires more than a full 64K block to sort more records.  The next version
 of XRS-Sort will use indirection to support sorting up to 7500+ messages.
 NOTE: enabling "XRS-Sort" as your preprocessor also creates threading even
 if none existed in the mailbag!  (this program is inside "XRSORT01.ZIP")

40) Several changes had to be made to the internal working of XRS to allow
 a MAILxIDX.XRS to be sorted "in place" (like 'XRS-Sort' will), since XRS
 has always expected the MAILxIDX.XRS order to be the same as the BATxMAIL
 file (which is *not* rearranged by 'XRS-Sort').  XRS will test the pointers
 to messages and ends-of-messages and if they are not normalized (i.e. in
 strictly ascending order), it will do a quicksort to fix up the end-message
 pointers after loading the MAILxIDX.XRS file.  This causes a slight delay,
 during which a message informing you that the sorted message index is being
 "fixed" for quicker access.

41) Any parameter in "CONFIG.XRS" which formerly required underscores ("_")
 no longer needs them - i.e. "Twit First Last" or "AutoTag Mike Ratledge",
 will work.  Underscores are still stripped for compatibility.

42) A small program named "EMSCHECK.EXE" is included which thoroughly tests
 your system's LIM/EMS memory funcionality, compatibility and usage by other
 programs.  If you have problems with caching overlayed versions, EMS access
 or swapping to LIM/EMS, run this program to check out your EMS driver.

43) If you have poor response in the internal editor when editing large files
 due to all the new edit information being constantly updated ("line x of y
 column z"), putting "SlowEdit x" in CONFIG.XRS causes the editor to update
 the location only when there are no keys to process, and no more than 'x'
 times per second (the range is from 1 to 10 for once per second up to every
 tenth of a second, and defaults to once per second).  You should enable this
 option only if you are unable to find a "TimeAdjust" that lets the internal
 editor respond smoothly when editing large messages.  This only affects the
 updating of the "Line x of y Column z" which requires a complete traversal
 of the entire internal editor buffer ("Mark", "xxx Free" and "Insert" are
 still instant).  XRS now only calls all background routines when there is
 nothing in the input queue (key and mouse input buffer) instead of callling
 it even when there is input still unprocessed.

44) If the last line in an exported message doesn't end in with a <CR>, it
 is now properly written to the output file anyway.

45) XRS has been moved from Turbo C 2.01 to Borland C++ 2.0 - please watch
 for things that don't work exactly as they did before!  Also, this should
 make things generally "snappier", because a lot more of the low-level
 functions are coded in assembler and compiler optimization is improved.  I
 also modified the code so it could be compiled under Microsoft or Zortech
 to aid in conversion for OS/2 and DOS/Extended versions and also to take
 advantage of better code optimization available when using those compilers.

46) You can use XRS-Sort.Exe to rearrange the mailbag, and still see the
 <J>ump list in numeric order by using "Sort Numeric".  This parameter is
 ignored if a normal mail index is found (if XRS doesn't have to normalize
 the mail index pointers to the end of each message).

47) In a couple of places, I was calling DOS shells without checking to see
 if "SET COMSPEC=" was not set properly (and therefore calling "NULL").  I
 now always call "COMMAND.COM" if COMSPEC is not set.

48) Having an XORIGIN.XRS in a mailbag no longer causes you to have to exit
 and restart the program after you open a new mailbag or "sticks" for the
 following mailbag.

49) The missing "* Forwarded Privately in Response to a Message in AREA: xxx"
 attribution line in netmail when replying to echomail messages has returned.

50) You can sort the <J>ump list by Subject, Sender or Number, or leave it in
 unsorted order (which might be numeric if you don't use XRS-Sort, or could
 be Subject, if you use XRS-Sort).  New parameters "Sort by Name" and "Sort
 Numeric" can be specified instead of "Sort Subject", and all four states can
 be cycled through from the <F4> hot-keyed configuration menu.  Unfortunately
 in coding this section, I noticed a bug that had been with us for a while
 that either just seldom occurs or noone has noticed: you cannot sort any
 list when it has been virtualized - it will have wierd effects on both the
 list contents and formatting thereof.  (so if you're in a virtual list, any
 sorting you have picked is ignored!)

51) If you have only one message area in a mailbag you no longer get into a
 loop (which you can only get out of with <ALT_F10>) repeatedly telling you
 there are no more unread messages.

52) XRS recognizes "Local" groups (if set properly in the BBS group/area
 configuration file), and appends a special tagline, complete with a random
 bragline (if applicable) that looks like " * XRS 4.52 : Your Bragline Here"
 and does not append any SEENBY or PATH lines.  The "Local" message bragline
 looks sort of like a Fidonet-style origin.

53) The binary native language support overlay (formerly XRS$ALL.DTA) is now
 named "XRSLANG.DLL" instead.  This is more consistant with current naming
 conventions, since this file contains all the language "resource" data.

54) Found a major whole in the woodwork in external editor support.  It was
 formerly possible to create a file too large to be saved, and XRS wouldn't
 "know" it and would overwrite itself in memory causing a crash or lockup.
 Now, if you create a message that is too big, you get a warning message,
 the file is saved as "BACKUP.XRS" and you can edit it externally and then
 import it into a new message to recover it.

55) Aliases are only supported for users with XRSDoor 2.04 or later, or if
 the door author has contacted me for specifications to enable it in their
 mailbagger program.  If XRS finds and "old style" user file, even if it has
 an alias, it will ignore it.  NOTE: previous versions of XRS will choke on
 the user file if alias support is enabled!

56) If the "Alias Required" bit is set in ACCESSx.XRS, a user alias is always
 used.  If the user doesn't have an alias, he cannot enter a message in this
 type area.

57) Messages in the first "LOCAL" group display "LOCAL" as the area tag in
 the "Select Area" pick-list, not "Group_xx" where 'xx' = the group number.

58) If you want the "Use Alias?" to default to no when you have a choice (it
 normally defaults to YES, put "Alias Default No" into CONFIG.XRS - in this
 case hitting just <Enter> at the above prompt will *NOT* use your alias.

59) "Delete All Read Messages?" works correctly for mailbags other than '1'.
 (i.e. ones with BAT2MAIL.XRS, SUMMARY2.XRS, etc).

60) When running a "DosCommand()" (using <F10> or <Shift_F10> keys) XRS
 clears the screen and uses the normal underline cursor.  Even if you are
 using a "fastscroll" ANSI.SYS replacement (like FANSIconsole, NANSI, etc)
 the "Press any key to continue..." message is always displayed onscreen.

61) Under OS/2, the output of external programs is always forced to CON: by
 turning on "Force Redirect".  Forced redirection is enabled for all external
 prgoram calls include DOS Shell (on tge <F10> hot-key) and DOS Command (on
 <ALT_F10> hot-key) except external editor calls.  I have to assume you are
 using an external editor that properly handles screen output using direct
 screen writes rather than risk disabling potential error messages, etc.

62) If you pick "Repack" or "Delete" in the "Handle Empty Mailbag" submenu,
 the screen is completely cleared instead of leaving the bottom portion.

63) Support for PKZip/PKUnZip v 2.0 added.

64) The signoff message ("Thanks...  Elapsed Time xx") is always yellow.

65) An extranious ";" on the end of a statement caused XRS to sometimes
 enable the cursor when it should not have after calling external programs.

66) After a netmail name lookup, the address is displayed for a minimum of
 around 1 1/2 seconds, even if "Pause 0" is in effect - so you can see it.
 The "Not found" message also no longer instantly disappears if you have any
 alternate namelists defined.

67) Trying to tame DesqView's voracious habit of eating complete time-slices
 whether it needs them or not, I no longer release time to DV when idle (i.e.
 waiting for input) more than once per second.

68) The cursor is reenabled during an exit caused by tampering with either
 the XORIGIN.XRS or USER1.XRS file - "Bad User" _exit(90) or _exit(91).

69) Having XRS clear the input buffer every time the "SelectArea()" pick list
 was displayed (a new feature in 4.51 beta) disabled "Auto Cycle" - fixed.

70) Disabling sound output at runtime should be "global" - i.e. there should
 no longer be any 'leaks' to the "Bell()" call.

71) In looking for bizarre inexplicable failures of "Auto Cycle" and ability
 to read messages in an area after "Read Only New" was disabled turned up an
 ancient, long-existing bug which was fixed.  This random corruption of data
 in memory by copying a string of up to 34 bytes into a 12-byte area could be
 the source of many long-standing "I dunno" and "it only happened once" type
 bugs as well.  This bug was turned up in a routine that hasn't changed in
 over two - maybe even three years...  (you programmer-types out there should
 invest in copies of NuMega's "Soft-ICE" and "Bounds Checker" programs!  You
 learn to live with and hate debuggers, so you might as well use the best
 tools you can find!)

72) If you do netmail auto-addressing (hit <INS> when prompted for a netmail
 address), the match must be exact (i.e. "All" doesn't match "Allen, Bob").
 This is another bug that has existed since "day one"...

73) If threads were 'synthesized' by XRS-Sort or any other "Preprocess", and
 therefore there is no "Thread" noted in the message header, I automatically
 place one when I highlight the blinking ('live') "«" or "»" thread symbols.
 I also corrected a minor buglet I hadn't noticed: those were supposed to be
 highlighted in Yellow on Red, but I wasn't setting the background properly.

74) XRS clears the screen and displays a message as soon as it starts to load
 ("Loading..."), and the "$$ACTIVE.XRS" found warning message is clearer.

75) XRConfig.Exe (and XRConfig.Dat) are searched for when you use the config
 <F4> hot-key, and if found, XRS offers to call the program if you hit <F4>
 again.  It displays a "bottom-line help" notifying you if the option is
 available.  Note that "XRCONFIG.EXE" (the freestanding XRS Configuration
 Program) is not yet available at this time.

76) You can switch "swapping" (to EMS or Disk) on and off with <F12> hot-key.
 A message detailing what you did is displayed on-screen.  The swapping status
 is also shown as part of the <F2> status hot-key display.  For those of you
 that don't have function key 11 or 12, use <ALT_F9> instead.

77) The mouse is not disabled when the "Delete all read messages?" query is
 displayed.

78) You can enable and disable LIM/EMS usage (and EMS status check) with the
 <F11> hot-key.  It can also be turned on and off with <SHIFT_F9> if you do
 not have a 101-keyboard.  A display is shown at the top of the screen.

79) XRS places a random byte into the RESPONSE.XRS so XCS can provide random
 braglines for QWK systems.






Changes from XRS v 4.50 (Release 3) -=> v 4.51 beta (Released 16-Sept-91):


1) The cursor inside the internal editor starts in "Half-Block" size, which
 corresponds with the default "Insert" mode.  If you toggle to "OverType" the
 cursor becomes the normal (underline) size and vice-versa.

2) If you put "LapTop" in your CONFIG.XRS file, XRS will normally use a block
 cursor in the internal editor for overtype mode (instead of the underline),
 which is sometimes not as easily located on laptop and notebook displays.

3) XRS restores the cursor to normal (underline) on exit and Shell-to-DOS.

4) If you are using a non-TCommNet system, XRS finds and nukes the first
 group (other than 0) that is labeled "LOCAL" so it doesn't show up twice.

5) In the "<J>ump" list, the <F3> ("Modify") key sets or resets the "Tag for
 Export" bit allowing you to easily select multiple messages to export (works
 similarly to setting the "read" message bit with <F5> key).  Note that using
 "Tag" in the "<J>ump" list this way both tags a message *AND* marks it read
 (or vice-versa) at the same time - in other words, if you tag it for export,
 I assume you don't want the message to be displayed as well.

6) Added an industrial strength assembler mouse cursor reinit function.  It
 =should= work on any @$&# thing with a tail!  Daan - please let me know.  It
 completely reinitializes the mouse, recomputes the mickey-to-pixel ratio,
 centers the cursor and turns it on.  If that doesn't work, your mouse driver
 is really unusual!  It is located on the (secret) hot-key <CTRL_F9>...
 The Mouse Resucitate (on <CTRL_F9> hot-key) now should work whether or
 not XRS thought you had a mouse, whether or not it is "hot" when you come
 back from an external program and whether or not the program thinks the
 mouse cursor is invisible or not.

7) I completely bypass the LIM/EMS checking in <F2> if "NOEMS" is specified
 as a parameter in the CONFIG.XRS file.

8) I don't hard-code the word "None" in some places I missed it before, but
 use the NLS (native language support) overlay message instead (in other
 words, it shows in your native language).

9) In the <F2> Status hot-key display, XRS detects and displays the LIM/EMS
 version and page frame, DMPI or VCPI mode and XMS driver and their version
 numbers, DesqView and QEMM and their version number(s) if any, plus the DOS
 version as well.  Also added better NLS (binary Native Language Support
 overlay) usage for "Free", etc. (and the total LIM/EMS RAM is correct, too)

10) If XCS.Exe and XRSlice.Exe are both found on the PATH, then XRS offers
 to remove (delete) all messages you have read.  The default is "No" unless
 you add a new CONFIG.XRS parameter "Delete Read Usually", in which case the
 default is "Yes".  "Delete Read Never" causes prompt to never be displayed.
  (If you haven't read any new messages during the session this is skipped.
   If you have read all messges this is skipped, but you can delete the
   mailbag by selecting "Delete" or "Repack and delete" from the list-box.)

11) "AutoTag" and "AutoMatch" are all run in a single pass - from 1 to 20 of
 them possible, and may now be mixed and matched instead of one "AutoTag" and
 up to 10 "AutoMatch" parameters.  Not only is this much faster (by a factor
 of up to 10), if most parameters are "AutoMatch" types, after each message
 is matched, the search can skip to the next message without even checking
 the remaining entries (unless some are "AutoTag" types and the message has
 not already been tagged for export).  This also gives extreme flexibility in
 the taggings for export and/or marking "Matched" routines, since all 20 are
 marked at once in an "OR" fashion.  (yielding the ability to mark 20 strings
 in less than the time that it used to take for two!)

12) When in the internal editor, XRS displays "Line x of x Column y" instead
 of just the current position in the window.  Also, all of the displays
 around the window frame in the internal editor are in the native language.

13) The previously "secret" (undocumented) quote cleaning hot-keys (on both
 <ALT_F3> for "Create Quote Lead-In" and <ALT_F5> for "Delete Quote Lead-In"
 have been repaired and should work properly.  To use <ALT_F3>, position the
 cursor over a space and <ALT_F3> will cut a quoted line in two, starting the
 new line with the identical quote lead-in which was found on the line before
 it was cut in two.  To use the <ALT_F5> key, position the cursor over the
 space *before* an existing quote lead-in, and <ALT_F5> will remove the quote
 lead-in.  (XRS now also finds and uses the quote lead-in on the current line
 instead of just inserting a quote lead-in to the person you are replying to.)
 Taking a quote lead-in out both measures the size of the quote lead-in at the
 start of the line (to determine how many characters to delete), and also
 checks to see if it is at the beginning of a line, and if so, "closes up" the
 two lines (it intelligently joins them if and only if required).

14) The "From" line in the header of archived messages is fixed.  (it now
 also shows the BBS/ID in addition to the filename - it used to show a random
 string, which sometimes made the right-hand margin go over 79 characters...)

15) XRS_Pack no longer puts a space between the "AREA:" kludge and the area
 name.  This was per FTS-0004, but common practice seems to indicate that 90%
 of other programs do not do this and 50% of the rest get stupid if you do.
 (in other words, the specs say they should be there, but I took them out...)

16) When you use an external editor, instead of "Save Message?", XRS prompts
 you with "Retain Message?" (in other words, it lets you know that if you
 pick "No", it will discard the message entirely - not just the edits you
 may have just done - if you think about this, XRS has no way to intelligently
 back out or "undo" changes you made with an external editor!).  There is also
 a new context-sensitive help screen for this prompt which clearly explains
 what action will result for each choice (if you hit <F1> at the prompt).

17) "Mark" displayed during block mode is also blinked, to help highlight it.

18) XRS$CORE.RTL has been renamed XRSCORE.RTL, but all your related programs
 will need to have the old one until I compile new versions of them!).  It
 was relinked with RTLink+ 5.00, and no longer has any problem(s) loading
 into DOS 5.0 with more memory than RTLink+ 4.10a thought was possible (which
 gave the erroneous "est0001 - illegal format in loadable file" message).

19) Added a new context-sensitive help screen for "Remove Read Messages".

20) As the amount of memory I can overlay increases, I have to increase the
 amount of LIM/EMS (both versions) or XMS RAM (in '286 versions only) of the
 overlayed executables.  Version 4.51 allocates 128K LIM/EMS or the exact #K
 it needs (somewhere around 116K) for overlay caching in XMS if available
 (limited however much is available - previous versions would allocate only
 up to 96K maximum).  This change allows overlayed versions to run in about
 the same amount of memory as previous versions, although the 4K edit buffer
 and backup size increased.  Most immediate noticable change should be that
 absolutely no overlay cache "thrashing" should occur whatsoever any more -
 meaning if you have sufficient memory to cache them all, they will never be
 read from disk and the program will run at 100% of the speed of non-overlay
 versions.  You should never see the disk light glowing when XRS is waiting
 for input or during background routines or in any cases except when it must
 actually read messages off the disk, etc.  This is a change from previos
 versions which did not cache into XMS, but "plain" extended memory.

21) Native language replaces hard-coded English in the "Search/Tag/Match"
 routine (the "Found! In Message #", "lines scanned", etc).  Elapsed time at
 program exit is also displayed in the native language.

22) XRS validates the external XRS$ALL.DTA file before using it.  If it is
 out-of-date, it tells you so and exits.

23) XRS insures it is running under DOS 3.0 or later - if not, it exits.

24) The input queue is cleared of keystokes and mouse input immediately before
 the "Select Area" list or "Auto Cycle" message are shown.

25) The non-286 overlayed version will now use XMS to cache overlays if no
 LIM/EMS is available.  (recent versions only did so for the 286 flavor)

26) A minor coding error chopped off macros that were between 74 and 80 bytes
 long (shortened them down to 73 characters) - fixed!

27) A completely new "Import()" routine for inserting files into the internal
 editor was written.  It now also checks to make certain the addition will not
 overflow the edit buffer before allowing import.

28) The incredibly sneaky (but slow) Import file (hot-key <ALT_F4> in the
 internal editor) was replaced by a direct buffer-to-buffer copy and updating
 the "_editInfo" structure.  Time to import any size file is basically nil, as
 compared to (up to) minutes in previous verions.  The display of available
 buffer space in the error message "file is too large..." was also corrected.
 As part of this change, I continually show the free buffer space left in the
 internal editor in the lower left-hand corner of the editor window (if you
 don't have "No Edit Info" in CONFIG.XRS).  This indicator starts to blink if
 you exceed 12,000 bytes in the buffer (an arbitrary threshhold, set by the
 ZEC in Zone 1).  Messages over this length may not be transported correctly
 (by the FidoNet "backbone" - this has nothing to do with an XRS problem!).

29) Macro-keys (on hot-keys <CTRL_F1> to <CTRL_F8> are also directly copied
 into the edit buffer and therefore I eliminated the extra-large preallocated
 input queue, saving around 1k more code-size and data-size.

30) The internal editor buffer-size is settable by "EditBuffer xxxxx" in the
 CONFIG.XRS file - default is 10k (10240 bytes).  The default leaves 4k more
 free memory than previous 4.50 and earlier overlayed versions, and 12k more
 RAM free for non-overlayed versions.  You can adjust it anywhere in a range
 of 8192 bytes (to limit memory usage) or up to 65500 bytes - double this
 amount you specify is used for the edit and backup buffers (in other words, a
 10k buffer takes 20k to store - because of the backup, and a 64k buffer takes
 128k to store).  See next two parameters, also.  Setting this to any value
 higher than 12,000 may earn you a warning message from "GMD" (the "Grunged
 Mail Detector) running on Tony Davis's and other backbone system.  FTS-0001
 states that message text is "bounded by a <NUL> character", which means
 unlimited in size.  Most QWK style systems only accept 99 lines of 77
 characters, so be careful what you feed these limited-thinking programs!

31) To change the buffer overflow warning threshold (which is 12,000 bytes by
 virtue of the current Fidonet Zone 1 backbone echomail "operating procedure")
 use "BufferWarn xxxxx" where 'xxxxx' is in the range 12,001 to 65,500 bytes.
 This controls when/if the "xxxx Free" blinks in the internal editor.  The
 default is FidoNet Zone 1's 'backbone' limit of 12,000 bytes.  Setting this
 to a higher value may earn you a warning message from "GMD" (the "Grunged
 Mail Detector) running on Tony Davis's system.  The 'warnsize' is adjusted
 by the number of lines in the message, since writing it will reduce the
 filesize by one byte per <CR><LF> changed to a <CR> only.

32) XRS 4.51 has been tested under MS/DOS 5.0, DR DOS 6.0, QEMM 6.0, HiMem.Sys
 3.0 and DesqView 2.4, none of which cause anything "funny" on my machine.
 Under DesqView you need "Virtualize Text and Graphics" set to 'T' for 'Text'!

33) SysOp using "XORIGIN.XRS" is fixed (no longer ignored resulting in an
 empty origin line).

34) Excellent professional/commercial quality printed and bound manuals for
 both XRS and XCS are available.  These were produced by Rudi Kusters using
 PageMaker 4.0, and printed both here in the states and in the Netherlands -
 both 3-ring binder punched and "tape" bound, so they can each be used like a
 book, or the spine split to be placed into a 3-ring binder for convenience.
 Each has a multi-color cover and stiff back cover for excellent usability.
 Both manuals are considerably nicer than the standard on-disk documentation!
 Each manual is available for $12 including shipping and handling charges, or
 together for $20, or in combination with an XRS or XCS voluntary upgrade
 fee for $25.  Also, you can purchase the "All of the above" option for $60,
 which includes perpetual (one-shot or lifetime) user licenses (registration)
 of XRS, XCS and manuals for current versions (from either Rudi or myself).
 A diskette upgrade service is also available - see DISKETTE.ETC for details.
 These services will become available starting sometime around November 1st
 from both Rudi in the Netherlands and myself here in the US.  The exact
 availability date will be announced in the QMX_XRS support echo on FidoNet.

35) "AutoTag" parameters only tag a message for export one time - once they
 have been exported, it will only mark the message as "matched".




 The following changes were made in "Release 2" or "Release 3" of XRS 4.50:
    (depending upon which 4.50 you had, these may are may not be new...)


1) ARJ format mailbags are supported.  Extension used is ".JXR".  PKZip.EXE
 (if found on the PATH) is still the default - you must specify archiver you
 wish to use other than PKZip with the "PACKER ARJ" parameter, for example.
 (note that leaving the '.EXE' extension off the packer statement no longer
 causes a problem, either)  For backwards-compatibility, this XRS version
 still uses only PKZip, LHA or PKArc to pack response mailbags (if you have
 ARJ selected, it will use PKZip instead for this one function).

2) LHA file creation problem fixed.

3) True 4D is used in *.PKT header if the program finds a "4D_PACK.XRS" file.

4) XRS stores "???_ONLY.XRS" with a mailbag (as well as "4D_PACK.XRS").

5) XRS computes the exact amount of memory to swap out to LIM/EMS or disk if
 you enable swapping, rather than fudging the "FarCoreLeft()" amount by 16k.
 In most cases, this should cause the swapped file or LIM/EMS size to be one
 block (or 16k) smaller.

6) Messages which are replies to message numbers from 32768 up to 65535 are
 displayed correctly in the "Create/Edit/Delete" list.

7) Netmail message headers that are modified with <F3> no longer cause an
 incorrect " * Forwarded privately in response..." to be inserted.

8) Netmail address "grabbing" from echomail messages is improved and more
 likely to have the correct address as the default if you reply privately.

9) XCS version number used on tearline problem fixed.

10) XRS remembers the name of the last imported file (using the<ALT_F4> hot
 key in the internal editor).

11) XRS puts the version number, etc. into the file named "$$ACTIVE.XRS",
 so external programs can tell which version of XRS it is running under.

12) "Compress Mailbag" is selected, the mailbag is no longer compressed
 *and* deleted (only compressed).

13) If a subject you quote is too long to fit into the new subject field
 (more than 25 characters in "QWK" mode or 70 characters in native mode)
 it is clipped to fit.  This previously caused a "Portal Error" message.

14) The last block of LIM/EMS memory used by the HX routines to preload
 the summary information (assuming you have LIM/EMS and didn't exclude
 using it) is not nuked on shell to DOS or calling an external program.
 This is done by "locking" 16k blocks of LIM/EMS memory (only one at a
 time) so other parts of the program that use LIM/EMS (like "Swap" or
 caching, or some external programs) don't destroy the contents of the
 LIM/EMS page-frame by failing to save and restore the "context" when
 they access (or rather change) it.

15) New "CONFIG.XRS" parameter 'Soft Fonts' causes XRS to not adjust the
 screen geometry when you return from a DOS shell or swap/shell.  This
 must be used with "SET XRS=X" to be effective.  Normally, XRS restores
 the video mode which was in effect when you shelled out - with soft
 fonts, this could be problamatic - with hardware fonts, it is not.

16) Putting ^aPID: ("hidden") kludges into message is the default instead
 of putting XRS version information on the tear line.  XCS version (if
 XCS or QWK mail being read) *is* displayed on the tear line - whether
 or not pids are turned on.  You can put "No Pids" into CONFIG.XRS to
 defeat this, but I would prefer that you not, and that programs not
 change the tear or pid lines after they are created - this should never
 occur!  The very reason they are there is to identify the originating
 program that injects the mail into the system, and altering them is a
 total defeat of that intent.  Several "QWK" style mail readers have
 given ORE ("Offline Reader Editor") programs a "bad name" on Fidonet,
 since they do not properly alter their behaivior to accomodate the new
 environment (which XRS does).  XRS 4.50 release 2 also only puts a BBS
 type in the address field of the Origin line.

17) A new text document named "OPTIMIZE.XRS" is included in this release.
 It details the best things to 'tweek' depending upon how much and which
 type(s) of memory you have, disk speed, etc.  All of these are done by
 changing and/or adding parameters to the CONFIG.XRS file.

18) If a "Bundler" is suppied, XRS uses it instead of the XRS2REP.EXE
 default.  Previously, XRS wouldn't use either (used "XRS_Pack" routines).